I’d like to make a plea for Skydemon to accept “Address Type” field values other than 1 & 2 in $PFLAA messages (i.e. in AirConnect and Pilotaware interface modes).
The concept of address types had been adopted by others, notably OGN, who have assigned different values (e.g. OGN use type 3 when transmitting their own, rather than ICAO addresses). When these addresses are passed to Skydemon in PFLAA messages, Skydemon currently rejects them, making it unusable with OGN devices (and possibly others) in this mode.
The specification of these messages originated with Flarm in their Dataport Interface Document, where currently only those 2 values are defined (for ICAO and FLARM addressing) which is, I assume, why SD reject other values. However the current Flarm Dataport Specification states, regarding the PFLAA message: “Data on other proximate aircraft, intended for connected devices with sufficient CPU performance. This sentence should be treated with utmost flexibility and tolerance on a best effort base.”
I suggest this is an invitation or indeed recommendation by FLARM themselves to accept other values. I suggest accepting any value in this field (I don’t think SD does anything with the present values anyway)? The alternative is that devices such as OGN or SoftRF will need to be tweaked to pretend the addresses are ICAO or FLARM when they are not. I have done this, and it works, but I feel the correct solution lies at the SD end.
Alan